Network devices, such as routers, are extensively tested to ensure that erroneous transmissions and fatal errors are minimized. A variety of test devices are available on the marketplace, including the ROUTER TESTER from AGILENT TECHNOLOGIES, assignee of the present application. Such test devices typically monitor the router's response to a variety of simulated input.
The process of routing can be quickly summarized as a node finding the path to every possible destination. Routing is present in everything from layer 1 (the physical layer) on up. The routing that most people are familiar with, however, occurs at layer 3 (the network layer) and as such, only layer 3 (and more specifically) Internet Protocol (IP) routing will be referenced herein. Routers use tables to determine where to forward packets. Updating these tables is a function performed by routing protocols. Each router is responsive to one or more protocols.
Protocols for exchanging routing information connect multiple routers around the world to provide them with a common view of the network through their heterogeneous, though generally consistent routing tables. Routing tables store all information necessary for the router to reach every destination on the network irrespective of size. There are a wide variety of routing protocols used to contribute to the routing tables across a network. Protocols such as BGP, OSPF, RIP and ISIS help to convey a correct and coherent picture of the network to all routers on the network.
Known router tester simulate network traffic using specifically created “test packets” of data that are typical of the live data present on the network. These test packets are transmitted to the network device over a network under test. Parameters tested by traffic simulator systems (including ROUTER TESTER) include routing verification, achievement of Quality of Service (QoS) levels under load, and correct inter-working with other devices. Many of these so-called “packet blasters” also test the ability of the network device to adhere to protocols by formulating and transmitting data in accordance with the protocols.
FIG. 1 is a block diagram of a traffic simulator test system 100. More particularly, the traffic simulator test system 100 is a general representation of ROUTER TESTER, offered by AGILENT TECHNOLOGIES. ROUTER TESTER is but one example of a router test system and in particular is advertised as a multi-port traffic generation, protocol emulation, and analysis test system for verifying the performance of enterprise, metro/edge, core routing and optical networking devices. The system generally comprises a plurality of protocol emulation cards 102n connected to a system under test, in this case a router 104. Each of the protocol emulation cards 102n generally comprises a processor with associated memory and I/O. The protocol emulation cards 102n are controlled by a computer 106, such as a PC running a WINDOWS environment. The computer 106 is responsive to an interface 108, such as a graphical user interface.
The test packets produced by the protocol emulation cards 102n are built according to the rules and interpretations of communications protocols, such as those defined by the many standards bodies in the industry. There are many communications protocols in use and new protocols continue to be developed. Typically, new protocols are initially developed by equipment manufacturers and are proprietary in nature. Often, the protocols are subsequently adopted by standards bodies for widespread implementation in industry. The protocol emulation cards 102n use protocol state machines to create data for transmission in accordance with the subject protocol. The state machines are similar in operation to the state machines used in the routers themselves.
The current software architecture associated with traffic simulator test systems requires hard-coding all parts of the protocol emulation solution including the graphical user interface, scripting API, configuration and control components, along with the protocol state machine itself. The hard coding required for each protocol has resulted in the use of an enormous amount of human talent to create the large body of code. Much of this code is dedicated to interfacing the computer 106 with each new protocol emulation card 102n. 
The traditional approach to interfacing the computer 106 with each new protocol emulation card 102n requires methods and associated parameters to be known at the time the interface is written and hard coded in an interface description language (IDL). Under this paradigm, new methods and parameters are continually being created each time new protocol emulations are written or old protocols are extended. This has resulted in a vast API (application programming interface) containing many hundreds of methods and parameters, resulting in a body of code that is expensive to maintain. Further, the known approaches result in the API being replicated at several different layers, thereby compounding the problems. Thus, each change to the API (no matter how small) requires the updating of a significant amount of code and different levels within the system. One side effect of this approach is that a unique GUI (graphical user interface) must be generated for each protocol and each update thereof. As with the API, as the number of protocols grow, so do the required GUI implementations.
Efforts are now being made to design generic systems that alleviate some of the foregoing problems. One example is described in co-pending U.S. patent application Ser. No.: 10/266,507, Publication No.: U.S. 20040068681 A1, entitled: Building packets of data. U.S. 20040068681 A1, incorporated herein by reference, uses an external protocol emulation description to drive a generic protocol data unit (PDU) encode/decode engine. A next step is to build a generic interface to the protocol emulators that do not require new code or hard coded interfaces changes for each new emulator or change thereto.
On approach to this situation is to develop a proprietary compiled language for controlling protocols. Language statements are written and compiled on the host computer and the resulting object files are distributed to the embedded software modules for execution. Under this approach, new language statements are needed for each protocol developed. This requires continual reworking of the compiler, which by its nature is a complex, highly skilled task. Further, GUI development remains a large ongoing task for each protocol.
Another approach is to develop a conventional, non-generic, application framework. This approach requires protocol emulations to be built within fixed, pre-defined APIs and data structures, or the framework be heavily customized for each protocol. Experience with real-world protocols suggests that heavy customization is necessary, making this approach unsatisfactory.
Accordingly, the present inventors have recognized a need for a generic framework that interfaces with applications based on definition files external to framework. To adapt the framework for a different application would only require the creation of a new definition file as opposed to the reworking of the framework itself. In the context of a protocol state machine, such a framework would enable the use of a plurality of user interfaces, including a generic GUI, capable of supporting all protocol emulations; a generic control and command host component; and a generic protocol housing on the embedded device.
In the description contained hereinafter, the use of a lowercase “n” adjacent to an element identifier denotes a non-specific instance of an element within a group of elements rather than a specific element as shown in the figures or discussed in the specification with a non-italicized letter adjacent to the element number. In the case of a group of elements sharing a common element identifier, the use of such element identifier without an adjacent letter refers to the group of elements as a whole.